New answers tagged

0

Thank you Azendale, upon running your test I found that the file was not 0 bytes. So I went into all of my startup scripts specifically .bashrc and commented out... #echo -e "Welcome to $LLVER ${USER}" #echo " " #date "+%A %d %B %Y, %T" #free -m | awk 'NR==2{printf "Memory Usage: %s/%sMB (%.2f%%)\n", $3,$2,$3*100/$2 }'...


0

This is what I ended up doing: I returned the DX517 expansion unit because it couldn't be powered down (to carry offsite) without powering down the NAS. I didn't want that restriction. I bought a second NAS (another DS920+ but that's likely overkill) installing the disks from the expansion unit and wiping them. Then I installed "Snapshot Replication&...


1

LTO 5 has 1.5TB physical capacity without any compression. Not normal, and looks like there is already some data on tape. It is possible to check free space on tape - Determine remaining capacity of LTO tape


1

Now based on your recent comment I can say that most likely it just run our of inodes. When you create ext4 fs by default mkfs allocates inodes based on partition/image size. So the less is the image size, the less is the inode count. You edit this script to allocate more inodes, just find a line where it does mkfs.ext4 and change the number of inode it ...


3

Absolutely not. A Domain Controller is not a stateless server; quite the opposite: it hosts the Active Directory database, where everything about the domain is stored, including authentication for users and computers. Also, this database is replicated between all DCs in the domain, and they send updates each other and employ several solutions to ensure ...


1

This is not a good idea. You need to have multiple domain controllers, but they need to be online and communicating with each other. It's also not a disaster recovery plan. And no it may not work for a variety of reasons.


0

I know this is late, but can be useful for others. rsync is an invaluable tools to reduce network transfers, but it does not reduce required disk bandwidth for changed files with default settings as it first copies the entire file, then it applies the required changes and finally it renames the temp file to the original name. You can try with --inplace to ...


0

A solution could be to create a disk image on the remote location and mount it locally: # we assume that /mnt/backup is a mounted SHFS, SMB, etc share truncate -s 100GiB /mnt/backup/rsync.img # create image file mkfs.ext3 -F /mnt/backup/rsync.img # create filesystem echo -e "o\nn\np\n1\n\n\nw" | fdisk /mnt/backup/rsync.img # create partition mkdir /...


2

No, and you're unlikely to be CPU bound in this case anyway. Improve your backup strategy if you can, or live with slow backups but the only way to speed things up with the mechanism you have now is faster disks.


Top 50 recent answers are included