elliotp's questions

Exemplo de hardware/host:

• CPU moderna de 64 núcleos, memória de 128 GB
• 8 x Micron Pro 15,36 TB SSD u.2
• SSDs conectados por Oculink dedicado por dispositivo (sem compartilhamento de backplane ou PCIe)
• Ubuntu 20.04

Caso de uso:

• Um servidor de backup para centenas de hosts. O backup é realizado por meio de rsync incremental, envolvendo primeiro um rsync do host remoto e, em seguida, uma cópia local (usando cp) para criar um instantâneo. - - - Milhões de pequenos arquivos (e-mail, arquivos html etc) são típicos de um backup.
• A qualquer momento, o servidor pode estar lidando com 50 rsyncs de entrada (algo de criptografia leve da CPU e sem compactação)
• A redundância embora seja vantajosa, não é necessária. Na maior falha de unidade única.
• E/S local extrema necessária para rotação de arquivos
• O uso de rsync e cópia diferencial de link físico ('rsnapshot') não pode ser alterado, isso é exigido pelo software de backup que está implantado e já em produção - portanto, os instantâneos BTRFS estão fora de questão.

Cheguei a duas soluções possíveis:

1. Fragmente meu armazenamento de dados, sem redundância. Em um formato de base por unidade em BTRRFS e montagem com compactação LZO em linha.

• Vantagem: Simples e leve, sem sobrecarga de gerenciamento de raid
• Vantagem: Falha isolada, em caso de falha de disco, apenas uma pequena parte dos backups é perdida, que são rapidamente reconstituídas
• Vantagem: Capacidade total máxima obtida
• Desvantagem: Complexidade do gerenciamento de capacidade - não ter um grande volume significa equilibrar estrategicamente os dados em discos específicos para aproveitá-los ao máximo
• Desvantagem: A falha de disco perde dados

2. ZFS RAIDz1/2 em todos os discos para um grande volume

• Vantagem: redundância de falha de 1 ou 2 discos
• Vantagem: Fácil gerenciamento, tudo cabe em um volume gigante - muito espaço.
• Desvantagem: Perda de capacidade de 1 ou 2 discos

A pergunta: haverá uma sobrecarga significativa de gerenciamento de RAID ZFS que reduzirá o desempenho do array em relação à opção 1? - Em uma configuração projetada em todos os níveis para maximizar a taxa de transferência do disco entre o SO e os SSDs, na casa dos 10 Gigabits por segundo, a sobrecarga do gerenciamento do ZFS RAID causará uma queda significativa no desempenho e/ou sobrecarregará a CPU ou a memória?

Obrigada.

Estou trabalhando com hardware de ponta, mas estou atingindo gargalos de CPU em todas as situações ao tentar mover grandes quantidades de dados.

Especificamente, estou movendo grandes arquivos de imagem de máquina virtual (VHD) de 2 TB entre dois hosts Ubuntu.

Minha última tentativa levou 200 minutos para transferir 2 TB. Resultando em uma taxa de transferência de cerca de 170 MB/s.

Estou tentando técnicas como netcat e scp com cifra básica arcfour.

O hardware em cada extremidade é 6 x SSDs de nível empresarial em RAID 10, em um controlador RAID de hardware. Memória de 256 GB e CPUs Xeon V4. A rede é 20Gbe (2 x 10Gbe LACP).

Em todos os casos, a rede e o disco i/o têm bastante capacidade restante, o gargalo está atrelando 1 núcleo de CPU a 100% constantemente.

Realizei benchmarks básicos usando vários métodos, como segue:

Transferência de arquivos de teste de 30 GB

scp: reais 5m1.970s

nc: reais 2m41.933s

nc & pigz: 1m24.139s reais

No entanto, como eu criei um arquivo vazio para teste, não acredito que o pigz estivesse tendo que trabalhar muito. Quando tentei pigz em um arquivo VHD de produção, pigz atingiu 1200% de carga da CPU, acredito que isso começou a se tornar o gargalo. Portanto, meu tempo mais rápido foi definido por nc por conta própria.

nc atinge 100% da CPU em cada extremidade, estou assumindo apenas processando o i/o do disco para a rede.

Eu pensei em dividir o arquivo em pedaços e executar vários nc para usar mais núcleos, no entanto, alguém pode ter uma sugestão melhor.

Estou realizando uma nova instalação do Ubuntu Server, em hardware RAID 10, 6 x 1,72TB SSD, o espaço total para partição é de 5,8TB. O servidor será usado para virtualização KVM.

Eu aloquei 500 MB para /boot ext4

2GB para troca

Deixando 5.8T para / ext4

Com 5% de blocos reservados para a partição /, são 290 GB de espaço que eu gostaria de poder usar.

290 GB de blocos reservados são um exagero? Eu li para que é usado, mas estou recebendo opiniões contraditórias, alguns dizem que só precisa ser tão grande quanto o arquivo larges, outros dizem que é necessário.

Meu pressentimento é que as pessoas boas do mundo linux sabem o que estão fazendo e está definido para 5% por um motivo, mas eu gostaria de ter opiniões sobre isso.

Estamos no processo de migração das máquinas virtuais do Windows Server entre a infraestrutura de nuvem. Em determinadas circunstâncias (HyperV Gen2 UEFI), o sistema falhará ao inicializar, a menos que instalemos o driver de armazenamento pronto para inicialização pós-migração.

Enquanto isso funciona ao fazê-lo offline usando (por exemplo, o disco conectado a outro servidor e injetando o driver):

dism /image:C:\ /add-driver /driver:E:\win7\amd64\viostor.inf

Para agilizar o processo, gostaríamos de instalar o driver enquanto a máquina está online. Infelizmente o dism está exigindo que o disco esteja offline, retornando o erro "Este comando só pode ser usado com uma imagem offline".

Tentamos o pnputil para instalar o driver, mas isso não funciona, acreditamos que isso ocorre porque o pnputil é para hardware conectado sem driver atualmente.

Existe uma maneira de instalar um driver em uma imagem online?

Tenho uma unidade avariada num servidor FreeNas alojado na OVH. Eu preciso trocar a unidade, mas estou extremamente consciente de que eles estão puxando a unidade errada.

O FreeNas não está relatando nenhum número de série em sua GUI. Eu fiz o abaixo até agora, não sei como obter o serial do drive, ou melhor ainda piscar o LED?

    pool: vol0
     state: DEGRADED
    status: One or more devices could not be opened.  Sufficient replicas exist for
        the pool to continue functioning in a degraded state.
action: Attach the missing device and online it using 'zpool online'.
       see: http://illumos.org/msg/ZFS-8000-2Q
      scan: scrub repaired 0 in 15h23m with 0 errors on Sun Jul  9 23:23:55 2017
config:

    NAME                                            STATE     READ WRITE CKSUM
    vol0                                            DEGRADED     0     0     0
      mirror-0                                      DEGRADED     0     0     0
        4720622759705179538                         UNAVAIL      0    64     0  was /dev/gptid/2a4bad04-4573-11e7-bd76-001e67cb3c7a
        gptid/2af09f67-4573-11e7-bd76-001e67cb3c7a  ONLINE       0     0     0
      mirror-1                                      ONLINE       0     0     0
        gptid/2b9ad3ca-4573-11e7-bd76-001e67cb3c7a  ONLINE       0     0     0
        gptid/2c440267-4573-11e7-bd76-001e67cb3c7a  ONLINE       0     0     0
      mirror-2                                      ONLINE       0     0     0
        gptid/2ce91024-4573-11e7-bd76-001e67cb3c7a  ONLINE       0     0     0
        gptid/2d8f9a88-4573-11e7-bd76-001e67cb3c7a  ONLINE       0     0     0
      mirror-3                                      ONLINE       0     0     0
        gptid/2e376cc0-4573-11e7-bd76-001e67cb3c7a  ONLINE       0     0     0
        gptid/2edb2c23-4573-11e7-bd76-001e67cb3c7a  ONLINE       0     0     0
      mirror-4                                      ONLINE       0     0     0
        gptid/2f8402f6-4573-11e7-bd76-001e67cb3c7a  ONLINE       0     0     0
        gptid/302bfda0-4573-11e7-bd76-001e67cb3c7a  ONLINE       0     0     0
      mirror-5                                      ONLINE       0     0     0
        gptid/30d274f0-4573-11e7-bd76-001e67cb3c7a  ONLINE       0     0     0
        gptid/317ad2a6-4573-11e7-bd76-001e67cb3c7a  ONLINE       0     0     0
    logs
      gptid/cd56ac86-4576-11e7-bd76-001e67cb3c7a    ONLINE       0     0     0

Usando glabel para obter o dispositivo:

#glabel status | grep 2af09f67-4573-11e7-bd76-001e67cb3c7a
gptid/2af09f67-4573-11e7-bd76-001e67cb3c7a     N/A  mfisyspd5p2

Qual é o próximo?

Atualizações:

Uma leitura adicional mostra que esse problema seria simples se as unidades não estivessem conectadas a um controlador raid (tudo no modo de passagem), pois o smartctl forneceria as informações necessárias. Usando mfiutil:

#mfiutil show drives
mfi0 Physical Drives:
 9 ( 5589G) JBOD <HGST HUS726060ALS640 A2D0 serial=1EJ48KYH> SCSI-6 E1:S5
10 ( 5589G) JBOD <HGST HUS726060ALS640 A2D0 serial=1EJ49TKH> SCSI-6 E1:S2
11 ( 5589G) JBOD <HGST HUS726060ALS640 A2D0 serial=1EJ48EMH> SCSI-6 E1:S6
12 ( 5589G) JBOD <HGST HUS726060ALS640 A2D0 serial=1EJ4AS6H> SCSI-6 E1:S8
13 ( 5589G) JBOD <HGST HUS726060ALS640 A2D0 serial=1EJ49HWH> SCSI-6 E1:S9
14 ( 5589G) JBOD <HGST HUS726060ALS640 A2D0 serial=1EJ48RDH> SCSI-6 E1:S10
15 ( 5589G) JBOD <HGST HUS726060ALS640 A2D0 serial=1EJ48NVH> SCSI-6 E1:S1
16 ( 5589G) JBOD <HGST HUS726060ALS640 A2D0 serial=1EJ49T1H> SCSI-6 E1:S11
17 ( 5589G) JBOD <HGST HUS726060ALS640 A2D0 serial=1EJ48T9H> SCSI-6 E1:S4
18 ( 5589G) JBOD <HGST HUS726060ALS640 A2D0 serial=1EJ4BAMH> SCSI-6 E1:S7
19 ( 5589G) JBOD <HGST HUS726060ALS640 A2D0 serial=1EJ4A0JH> SCSI-6 E1:S3
20 ( 5589G) JBOD <HGST HUS726060ALS640 A2D0 serial=1EJ4AX8H> SCSI-6 E1:S0
21 (  149G) JBOD <INTEL SSDSC2BB16 0370 serial=BTWL340106TD160MGN> SATA E2:S4

Agora tenho números de série e dispositivos, como faço para mapear os dois juntos?

Tentando instalar o Ubuntu 16.04 Server em um disco recém-inicializado. Usando UEFI e uma partição / 4,5 TB. Depois de instalar sem problemas, ao reiniciar, o servidor não passará do Grub.

Hardware:

• Novo Servidor Supermicro
• Hardware 6 x SSD RAID 5 - disco virtual de 4,5 TB
• BIOS totalmente atualizado

Etapas de instalação:

Seleção do UEFI Virtual CD, que é o Ubuntu 16.04 Server. NOTA - Eu escolhi o UEFI Virtual CD em vez do destaque não UEFI, conforme mostrado na captura de tela (percebi depois de tirar a captura de tela)

Layout de partição guiada padrão do Ubuntu, não LVM, completamente inalterado. A confirmação de partições, incluindo ESP está presente.

A instalação é concluída sem erros. Após a instalação, o Ubuntu fica visível no menu de inicialização:

O sistema inicializa no Grub, independentemente da opção escolhida:

No Grub, pelo que entendi, o ESP deve ser montado em /boot/efi. No entanto, o Grub mostra erros como abaixo, mas também pode listar / normalmente, porém qualquer coisa dentro de / como /etc apresenta o erro, incluindo /boot:

O Grub mostra as partições como:

Não tenho certeza de como proceder a partir daqui.

Eu configurei o OpenStack - minha primeira vez. Eu segui o guia de instalação (no Ubuntu 14.04) e acredito que acertei tudo. No entanto, ao tentar criar uma instância, recebo o erro:

Construção da instância e948205a-2287-4b0e-9829-f2c6fe3a93eb abortada: não é possível estabelecer conexão com http://127.0.0.1:9696/v2.0/extensions.json

Estou depurando isso há cerca de uma semana e esgotei todas as soluções que encontrei no Google e nas quais consigo pensar.

Neutron está escutando na porta:

netstat -ln | grep 9696 tcp 0
0 0.0.0.0:9696 0.0.0.0:*
LISTEN

Também posso me conectar ao Neutron a partir da linha de comando:

root@controller:/var/log# neutron ext-list
+---------------------------+-----------------------------------------------+
| alias                     | name                                          |
+---------------------------+-----------------------------------------------+
| default-subnetpools       | Default Subnetpools                           |
| network-ip-availability   | Network IP Availability                       |
| network_availability_zone | Network Availability Zone                     |
| auto-allocated-topology   | Auto Allocated Topology Services              |
| ext-gw-mode               | Neutron L3 Configurable external gateway mode |
| binding                   | Port Binding  
...

Posso autenticar com um token e obter uma resposta do Neutron manualmente com o teste de curl abaixo, isso responde com os dados esperados.

curl -i -H'X-Auth-Token: MY_TOKEN' http://controller:9696/v2.0/extensions.json

Meus endpoints da API de nêutrons:

| 440735e5dd8d468e89de9a8077ea9491 | RegionOne | nêutron | rede | Verdadeiro | público | http://controller:9696 |

| 5985d944b02b4148a87cafae8df006c8 | RegionOne | nêutron | rede | Verdadeiro | interna | http://controller:9696 |

Verifiquei todos os logs do Nova e do Neutron e não consigo ver nenhum erro neles, recriei meus endpoints do Neutron, verifiquei e verifiquei novamente as configurações. Não sei como continuar a depuração ou onde está a solução.

Editar com informações atualizadas:

root@controller:~# openstack catalog list
+----------+----------+--------------------------------------------------------------------------+
| Name     | Type     | Endpoints                                                                |
+----------+----------+--------------------------------------------------------------------------+
| neutron  | network  | RegionOne                                                                |
|          |          |   admin: http://controller:9696                                          |
|          |          | RegionOne                                                                |
|          |          |   internal: http://controller:9696                                       |
|          |          | RegionOne                                                                |
|          |          |   public: http://controller:9696                                         |
|          |          |                                                                          |
| nova     | compute  | RegionOne                                                                |
|          |          |   admin: http://controller:8774/v2.1/225f1282f5034949937f5ef71c503dd0    |
|          |          | RegionOne                                                                |
|          |          |   internal: http://controller:8774/v2.1/225f1282f5034949937f5ef71c503dd0 |
|          |          | RegionOne                                                                |
|          |          |   public: http://controller:8774/v2.1/225f1282f5034949937f5ef71c503dd0   |
|          |          |                                                                          |
| keystone | identity | RegionOne                                                                |
|          |          |   admin: http://controller:35357/v3                                      |
|          |          | RegionOne                                                                |
|          |          |   public: http://controller:5000/v3                                      |
|          |          | RegionOne                                                                |
|          |          |   internal: http://controller:5000/v3                                    |
|          |          |                                                                          |
| glance   | image    | RegionOne                                                                |
|          |          |   admin: http://controller:9292                                          |
|          |          | RegionOne                                                                |
|          |          |   public: http://controller:9292                                         |
|          |          | RegionOne                                                                |
|          |          |   internal: http://controller:9292                                       |
|          |          |                                                                          |
+----------+----------+--------------------------------------------------------------------------+

Redes de nêutrons que criei via Horizon e CLI

root@controller:~# neutron net-list
+--------------------------------------+------------------+--------------------------------------------------+
| id                                   | name             | subnets                                          |
+--------------------------------------+------------------+--------------------------------------------------+
| 8a50aef6-b687-483d-ab49-f43460eebdd6 | My Admin Network | d4f840cc-31b9-4d32-963d-3a2110ae5765 10.0.0.0/24 |
| 8bb223ef-828d-4c9a-aa16-15ac13d244f6 | ext-net          |                                                  |
| 98a2606a-3017-48fb-8b60-e18c4a4f1083 | My Network       | b76352ac-dc61-4d75-ba7a-b5b4d76705d0 10.0.0.0/24 |
+--------------------------------------+------------------+--------------------------------------------------+

Minha lista Neutron Ext está abaixo:

root@controller:~# neutron ext-list
+---------------------------+-----------------------------------------------+
| alias                     | name                                          |
+---------------------------+-----------------------------------------------+
| default-subnetpools       | Default Subnetpools                           |
| network-ip-availability   | Network IP Availability                       |
| network_availability_zone | Network Availability Zone                     |
| auto-allocated-topology   | Auto Allocated Topology Services              |
| ext-gw-mode               | Neutron L3 Configurable external gateway mode |
| binding                   | Port Binding                                  |
| agent                     | agent                                         |
| subnet_allocation         | Subnet Allocation                             |
| l3_agent_scheduler        | L3 Agent Scheduler                            |
| tag                       | Tag support                                   |
| external-net              | Neutron external network                      |
| net-mtu                   | Network MTU                                   |
| availability_zone         | Availability Zone                             |
| quotas                    | Quota management support                      |
| l3-ha                     | HA Router extension                           |
| provider                  | Provider Network                              |
| multi-provider            | Multi Provider Network                        |
| address-scope             | Address scope                                 |
| extraroute                | Neutron Extra Route                           |
| timestamp_core            | Time Stamp Fields addition for core resources |
| router                    | Neutron L3 Router                             |
| extra_dhcp_opt            | Neutron Extra DHCP opts                       |
| dns-integration           | DNS Integration                               |
| security-group            | security-group                                |
| dhcp_agent_scheduler      | DHCP Agent Scheduler                          |
| router_availability_zone  | Router Availability Zone                      |
| rbac-policies             | RBAC Policies                                 |
| standard-attr-description | standard-attr-description                     |
| port-security             | Port Security                                 |
| allowed-address-pairs     | Allowed Address Pairs                         |
| dvr                       | Distributed Virtual Router                    |
+---------------------------+-----------------------------------------------+

Com o comando create with debug, agora tenho mais informações sobre o erro real (será melhor copiar e colar para ler):

{u'message': u'Build of instance 3e2f5678-6a4a-478b-8953-d10db929d367 aborted: Unable to establish connection to http://127.0.0.1:9696/v2.0/extensions.json', u'code': 500, u'details': u'  File "/usr/lib/python2.7/dist-packages/nova/compute/manager.py", line 1926, in _do_build_and_run_instance\n    filter_properties)\n  File "/usr/lib/python2.7/dist-packages/nova/compute/manager.py", line 2083, in _build_and_run_instance\n    \'create.error\', fault=e)\n  File "/usr/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 220, in __exit__\n    self.force_reraise()\n  File "/usr/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 196, in force_reraise\n    six.reraise(self.type_, self.value, self.tb)\n  File "/usr/lib/python2.7/dist-packages/nova/compute/manager.py", line 2067, in _build_and_run_instance\n    instance=instance)\n  File "/usr/lib/python2.7/contextlib.py", line 35, in __exit__\n    self.gen.throw(type, value, traceback)\n  File "/usr/lib/python2.7/dist-packages/nova/compute/manager.py", line 2244, in _build_resources\n    reason=six.text_type(exc))\n', u'created': u'2016-04-29T13:56:55Z'} |

Eu não sabia nada sobre vxlan até cerca de 30 minutos atrás, no entanto, tive um problema ao instalar o OpenStack, que está relacionado ao vxlan.

Tentando criar um vxlan em uma interface no Ubuntu 14.04 (kernel 3.14.32):

ip link add vxlan10 type vxlan id 10 group 239.0.0.10 ttl 4 dev eth0
RTNETLINK answers: Operation not supported

O Google não apresenta relativamente nenhuma informação sobre isso - não parece ser um problema comum.

É certo que o comando acima pode não estar correto, pois peguei um exemplo de outro lugar. No entanto, não tenho certeza se isso é um problema de suporte de hardware ou kernel.

Estou tentando configurar o Ubuntu 14.04 para atuar como um gateway NAT entre uma rede pública e privada.

• Interface Pública ->eth0 (178.x.x.x)
• Interface Privada ->eth0:0 (192.168.206.190/17)

Eu tentei muitas combinações de iptablesregras, mas não consigo rotear o tráfego. Confirmei que o gateway pode ver a Internet e os hosts na rede privada podem ver o gateway e o gateway padrão está definido corretamente.

net.ipv4.ip_forward=1está definido em sysctl.

Minhas iptablesregras estão abaixo. Minha iptablesexperiência é mínima, então é bem possível que eu tenha perdido alguma coisa.

# Generated by iptables-save v1.4.21 on Thu Apr 21 12:38:44 2016
*security
:INPUT ACCEPT [215:14912]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [133:16208]
COMMIT
# Completed on Thu Apr 21 12:38:44 2016
# Generated by iptables-save v1.4.21 on Thu Apr 21 12:38:44 2016
*raw
:PREROUTING ACCEPT [215:14912]
:OUTPUT ACCEPT [133:16208]
COMMIT
# Completed on Thu Apr 21 12:38:44 2016
# Generated by iptables-save v1.4.21 on Thu Apr 21 12:38:44 2016
*nat
:PREROUTING ACCEPT [3:132]
:INPUT ACCEPT [3:132]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -o eth0 -j MASQUERADE
COMMIT
# Completed on Thu Apr 21 12:38:44 2016
# Generated by iptables-save v1.4.21 on Thu Apr 21 12:38:44 2016
*mangle
:PREROUTING ACCEPT [215:14912]
:INPUT ACCEPT [215:14912]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [133:16208]
:POSTROUTING ACCEPT [133:16208]
COMMIT
# Completed on Thu Apr 21 12:38:44 2016
# Generated by iptables-save v1.4.21 on Thu Apr 21 12:38:44 2016
*filter
:INPUT ACCEPT [46:3296]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [28:3484]
-A FORWARD -i eth0:0 -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i eth0 -o eth0:0 -j ACCEPT
COMMIT
# Completed on Thu Apr 21 12:38:44 2016

iptables -L -v

Chain INPUT (policy ACCEPT 15 packets, 1044 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     all  --  eth0:0 eth0    anywhere             anywhere             state RELATED,ESTABLISHED
    0     0 ACCEPT     all  --  eth0   eth0:0  anywhere             anywhere

Chain OUTPUT (policy ACCEPT 10 packets, 1016 bytes)
 pkts bytes target     prot opt in     out     source               destination

Aqui está a configuração de um host na rede privada:

netstat -r
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
default         nat             0.0.0.0         UG        0 0          0 eth0
192.168.128.0   *               255.255.128.0   U         0 0          0 eth0

ping de 'nat' confirma que o host pode ver 'nat':

ping nat
PING nat (192.168.206.190) 56(84) bytes of data.
64 bytes from nat (192.168.206.190): icmp_seq=1 ttl=64 time=0.359 ms

ping de 8.8.8.8 não mostra roteamento de tráfego:

ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
^C
--- 8.8.8.8 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 1999ms

Configurei uma rotação de backup em um crontab centos 6, um script deve ser executado de segunda a sábado, o outro em um domingo, nunca no primeiro dia do mês. No entanto, o script semanal (somente domingo) foi executado todas as noites e o diário foi executado no domingo. Confirmado pelo cron.log

#Daily - Midnight, Mon-Sat, Not on the 1st of the Month
0 0 2-31 * 1-6 script_daily

#Weekly - Midnight, Sunday, Not on the 1st of the Month
0 0 2-31 * 0 script_weekly

Não consigo descobrir o que estou fazendo de errado?

Editar: extraí linhas relevantes do log do cron. Dia 28 foi um domingo.

Jun 28 00:00:01 backup CROND[2000]: (root) CMD (script_daily)
Jun 28 00:00:01 backup CROND[2004]: (root) CMD (script_weekly)
Jun 29 00:00:01 backup CROND[9438]: (root) CMD (script_daily)
Jun 29 00:00:01 backup CROND[9443]: (root) CMD (script_weekly)
Jun 30 00:00:02 backup CROND[6893]: (root) CMD (script_daily)
Jun 30 00:00:02 backup CROND[6898]: (root) CMD (script_weekly)